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Sir: 

We, Sowmya Subramanian, Ramu Sunkara, Kunal Kapur, Anthony Lai, Sarim Siddiqui, 
Sunny Wong, and Hyun-Sik Byun, declare as follows: 

1 . We are the named inventors of the above-identified application. 

2. Prior to December 18, 2000, we conceived and actually reduced to practice, in the 
United States, the invention disclosed and claimed in the above-identified application. 

3 . We have reviewed the currently pending claims of the above-identified application 
(i.e., claims 1-91), and to the best of our recollection, we believe that we had a definite and complete 

1 
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idea of, and had actually reduced to practice, the designs embodying all of the elements of claims 1- 
91 prior to December 18, 2000. Independent claims 1, 23, 49, 58, 63, 70, and 71 are set forth below: 

1 . A method for prefabricating an information page, comprising: 

prefabricating a first page in accordance with a definable prefabrication policy 

to produce a first prefabricated page, wherein the prefabricating is not in response to a 

request for the first page by a user; 

receiving an information request; 

determining if the information request corresponds to the first page; 
providing the first prefabricated page if the information request corresponds to 
the first page; and 

dynamically fabricating a second page if the information request corresponds 
to the second page; 

wherein the act of prefabricating the first page comprises querying a database 
to obtain cached data, processing the data received from the database, and packaging 
information associated with the data in a prescribed format. 

23. A system for prefabricating information, comprising: 

a prefabricator configured to prefabricate a first page to produce a first 
prefabricated page, wherein the first page is not prefabricated by the prefabricator in 
response to a request for the first page by a user, and wherein the act of prefabricating 
the first page comprises querying a database to obtain cached data, processing the 
data received from the database, and packaging information associated with the data 
in a prescribed format; 

an interceptor to intercept an information request, the interceptor logically 
interposed between a user interface and a computer application, the interceptor 
providing the first prefabricated page if the information request corresponds to the 
first page and dynamically fabricating a second page if the information request 
corresponds to the second page. 

49. A method for prefabricating information pages, comprising: 

prefabricating a first page on a first node to produce a first prefabricated page, 

wherein the prefabricating is not in response to request for the first page by a user; 
storing the first prefabricated page; 

prefabricating a second page on a second node to produce a second 
prefabricated page; 

storing the second prefabricated page; 
receiving an information request; 

providing the first prefabricated page if the information request corresponds to 
the first page; and 

providing the second prefabricated page if the information request 
corresponds to the second page; 
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wherein the act of prefabricating the first page comprises querying a database 
to obtain cached data, processing the data received from the database, and packaging 
information associated with the data in a prescribed format. 

58. A method for prefabricating an information page, comprising: 

prefabricating a first page to produce a first prefabricated page , wherein the 
prefabricating is not in response to a request for the first page by a user; 

receiving an information request from a user having a session identifier; 

determining if the information request corresponds to the first page; 

providing the first prefabricated page with the session identifier if the 
information request corresponds to the first page; and 

dynamically fabricating a second page if the information request corresponds 
to the second page; 

wherein the act of prefabricating the first page comprises querying a database 
to obtain cached data, processing the data received from the database, and packaging 
information associated with the data in a prescribed format. 

63. A method for prefabricating an information page comprising: 

obtaining one or more parameters that define how a page should be 
prefabricated; and 

prefabricating a page based on the one or more parameters, wherein the 
prefabricating is not in response to a request for the page by a user, and wherein the 
act of prefabricating the page comprises querying a database to obtain cached data, 
processing the data received from the database, and packaging information associated 
with the data in a prescribed format. 

70. A computer program product that includes a medium usable by a processor, 
the medium having stored thereon a sequence of instructions which, when executed 
by said processor, causes said processor to execute a process for prefabricating an 
information page, the process comprising: 

prefabricating a first page in accordance with a definable prefabrication policy 
to produce a first prefabricated page, wherein the prefabricating is not in response to a 
request for the first page by a user; 

receiving an information request; 

determining if the information request corresponds to the first page; 
providing the first prefabricated page if the information request corresponds to 
the first page; and 

dynamically fabricating a second page if the information request corresponds 
to the second page; 

wherein the act of prefabricating the first page comprises querying a database 
to obtain cached data, processing the data received from the database, and packaging 
information associated with the data in a prescribed format. 
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71 . (Previously Presented) A computer program product that includes a medium 
usable by a processor, the medium having stored thereon a sequence of instructions 
which, when executed by said processor, causes said processor to execute a process 
for prefabricating an information page, the process comprising: 

prefabricating a first page on a first node to produce a first prefabricated page, 
wherein the prefabricating is not in response to a request for the first page by a user; 

storing the first prefabricated page; 

prefabricating a second page on a second node to produce a second 
prefabricated page; 

storing the second prefabricated page; 
receiving an information request; 

providing the first prefabricated page if the information request corresponds to 
the first page; and 

providing the second prefabricated page if the information request 
corresponds to the second page; 

wherein the act of prefabricating the first page comprises querying a database 
to obtain cached data, processing the data received from the database, and packaging 
information associated with the data in a prescribed format. 



4. The set of documents attached as Exhibit A and Exhibit B evidences that we 
conceived of each and every element of each claim of the above-identified application, and reduced 
it to practice, before December 18, 2000. The document of Exhibit A, which was made prior to 
December 18, 2000, composed part of a design specification used internally by the assignee of the 
above-identified application. The document of Exhibit B is part of a presentation made internally 
within the company of assignee describing analysis results based upon running an implementation of 
the invention. The specification and the presentation material were not used earlier than one year 
prior to the filing date of the above-identified application. 

5. With respect to claims 1 and 70, Exhibit A shows a design specification for 
prefabricating an information page, that includes prefabricating a first page in accordance with a 
definable prefabrication policy to produce a first prefabricated page, wherein the prefabricating is 
not in response to a request for the first page by a user (particularly page 7, Section 3.1.1-3.1.2, and 
page 13, Section 3.4), receiving an information request (particularly page 20, Section 3.9), 
determining if the information request corresponds to the first page (particularly page 20, Section 
3.9), providing the first prefabricated page if the information request corresponds to the first page 
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(particularly page 20, Section 3.9), and dynamically fabricating a second page if the information 
request corresponds to the second page (particularly page 11, Section 3.2, and page 19, Section 3.5), 
wherein the act of prefabricating the first page comprises querying a database to obtain cached data, 
processing the data received from the database, and packaging information associated with the data 
in a prescribed format (particularly page 19, Section 3.6, and page 20, Sections 3.8-3.9). 

6. With respect to claim 23, Exhibit A shows a design specification for a system for 
prefabricating information that includes a prefabricator configured to prefabricate a first page to 
produce a first prefabricated page, wherein the first page is not prefabricated by the prefabricator in 
response to a request for the first page by a user, and wherein the act of prefabricating the first page 
comprises querying a database to obtain cached data, processing the data received from the database, 
and packaging information associated with the data in a prescribed format (particularly page 6, 
Section 3), an interceptor to intercept an information request, the interceptor logically interposed 
between a user interface and a computer application, the interceptor providing the first prefabricated 
page if the information request corresponds to the first page and dynamically fabricating a second 
page if the information request corresponds to the second page (pargicularly page 20, Sectin 3.9, and 
page 19, Section 3.5). 

7. With respect to claims 49 and 71, Exhibit A shows a design specification for 
prefabricating information pages, which includes prefabricating a first page on a first node to 
produce a first prefabricated page, wherein the prefabricating is not in response to request for the 
first page by a user (particularly page 1 1, Section 3.2, page 12, Section 3.3, and page 13, Section 
3.4), storing the first prefabricated page (particularly page 13, Section 3.4, page 19, Section 3.6, and 
page 21, Section 3.10), prefabricating a second page on a second node to produce a second 
prefabricated page (particularly page 12, Section 3.3, and page 13, Section 3.4), storing the second 
prefabricated page (particularly page 13, Section 3.4, page 19, Section 3.6, and page 21, Section 
3.10), receiving an information request (particularly page 20, Section 3.9, and page 11, Section 3.2), 
providing the first prefabricated page if the information request corresponds to the first page 
(particularly page 20, Section 3.9), and providing the second prefabricated page if the information 
request corresponds to the second page (particularly page 20, Section 3.9), wherein the act of 
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prefabricating the first page comprises querying a database to obtain cached data, processing the data 
received from the database, and packaging information associated with the data in a prescribed 
format (particularly page 19, Section 3.6, and page 20, Sections 3.8-3.9). 

8. With respect to claim 58, Exhibit A shows a design specification for prefabricating an 
information page, that includes prefabricating a first page to produce a first prefabricated page , 
wherein the prefabricating is not in response to a request for the first page by a user (particularly 
page 7, Section 3.1.1-3.1.2, and page 13, Section 3.4), receiving an information request from a user 
having a session identifier (particularly page 20, Section 3.9), determining if the information request 
corresponds to the first page (particularly page 20, Section 3.9), providing the first prefabricated 
page with the session identifier if the information request corresponds to the first page (particularly 
page 20, Section 3.9), and dynamically fabricating a second page if the information request 
corresponds to the second page (particularly page 11, Section 3.2, and page 19, Section 3.5), wherein 
the act of prefabricating the first page comprises querying a database to obtain cached data, 
processing the data received from the database, and packaging information associated with the data 
in a prescribed format (particularly page 19, Section 3.6, and page 20, Sections 3.8-3.9). 

9. With respect to claim 63, Exhibit A shows a design specification for prefabricating an 
information page, that includes obtaining one or more parameters that define how a page should be 
prefabricated (particularly page 11, Section 3.2, and page 12), and prefabricating a page based on the 
one or more parameters, wherein the prefabricating is not in response to a request for the page by a 
user, and wherein the act of prefabricating the page comprises querying a database to obtain cached 
data, processing the data received from the database, and packaging information associated with the 
data in a prescribed format (particularly page 13, Section 3.4, page 19, Section 3.6, and page 21, 
Section 3.10). 

10. The subject invention was reduced to practice and tested to verify that it works for its 
intended purpose prior to December 18, 2000. Exhibit B includes information which evidences that 
the subject invention was tested and found to work for its intended purpose. 
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11. We declare that all statements made herein of my own knowledge are true, and that 
ail statements made on information and belief arc believed to be true; and further, that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001. of Title 18 of United States Code, 
and that such willful false statements may jeopard^ the validity of the application or any patent 



issuing thereon. 



Date Sowmya Subramanian 



Date Ramu Sunkara 



Dato Knual Kapur 



Date Anthony Lai 



Date Sarim Siddiqui 
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11. We declare that all statements made herein of my own knowledge are true^and that 
all statements made on information and belief are believed to be true; and further, that theae ; 
statements were made with the knowledge that willful false statements and the like so made, are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of United States; ; Code, 
and that such willful false statements may jeopardize the validity of the application or any patent 
issuing thereon, 
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11. We declare that all statements made herein of my own knowledge are true, andthat 
all statements made on information and belief are believed to be true; and further, that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of United States Code, 
and that such willful false statements may jeopardize the validity of the application or any patent 
isisuing thereon. 
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JTF Page Fabrication service speeds up page delivery for JSP applications. 
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Vmloh: Oracle Confidential 



Design Specification f» r 



2 High Level Design 



The key idea behind page prefabrication is to create and store the HTTP r„™„« * 

prion, so that when an user actually requests the uw T HTT f. ^ponse for a URL request a 




Figure 1: Prefabricator with Jserv 



JSP 



Request^ 




Pmfabrfcator 




""Mretab 
Metadata 



File System 



I documentation on Apache can be found at: http^Avww.apache org 
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Design 



Figure 2: Prefabricates with Calypso 



The three main components: 

Prefabricate)!- : this intelligently collects/generates all the URLs to be prefabricated and issues the URI 
requests to get ,t prefabricated. Furthermore, this component needs toensure cons sSncl Tt£ 
prefabricated data. More details about this component follow. - "cyortne. 

tos^r: this intercepts the URL requests, determines if the request can be serviced from the cache or 
not. Funftermore, the interceptor needs to distinguish between "client" URL requests and the 
"prefabneator" URL requests. M 

Cache: this is responsible for storage and retrieval of prefetched responses 

TTie primary focus of fcis project is to build the prefabneator and interceptor technology. Existing caching 
teclmolog.es (such as Calypso) will be leveraged for the cache component. FoiiowinglubsectioirpS 
the above three components in more details. «^«|)(iui 
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Start Loader 

•generate homo page 
URIjb 

•generate user-defined 
URU 



{ Request Objects) 



Request Feeder 



•work queues for URL 
requests 
-process each queue Item 



{ Request Objects) 



Benefit Analyzer 



♦intervals to fssue requests: 
-resources 
•depth of tree 
-usage pattern 
- stateness 



{ Request Objects} 



Page Generator 



•send URL request to 
interceptor 



URL Collector 



■crawl through URLs 
■collect "Interesting" 
pages 

•feed URLs to benefit 
analyzer 



Figure 3: Prefabricator Design 



^d^flJl^^ ^ differCnt COmp ° nentS ° f * e ^ncator. Tfce basic unit of 
work done by the prefabricator is fabricating a URL: i.e., issuing a request to the web-server Tor 
mterceptor) to get the response generated. This section provides^ details abTuVe^ 
components in the prefabricator: 



Common Data Structures: 

• PageRequestBlock class 

• Policylnfonnation class 

• SystemStatistics class 
Components 

• StartLoader 

• BenefitAnalyzer 

• RequestFeeder 

• PageGenerator 

• URLCollector 



• Invalidator 
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3.1 Prefabricator Data Structures 
3.1.1 Page Request Block (PRB) 

„ Every URL that is a candidate for prefabricate is represented as a page request block. 

Station 68810 ^ StmCtUrC ** g6tS P3SSed ar ° Und *" SyStem- ft enca P sulates *« following 



Attribute 


Data Type 


Description 


URI 


String 


URI that the request represents 


userlD 


int 


userlD of the user this request belongs to 


appID 


int 


appID this request belongs to 


respID 


int 


respID of the user this request belongs to 


depth 


int 


starting from the home page, the number of pages to be 
navigated before this URL is reached A page is at depth 0 if 
it is the user's homepage, depth 1 if it is a page that can be 
reached directly from me home page, etc. Login page is at 
depth -1. 


Weighty 


long 


weight associated with this PRB 


homePRB , 


PRB 


PRB of the entry page to this application for the user 


file^ocator 


String 


location of the fabricated page on the file system 


requestTimeStamp 


Date 


time stamp when request block was created 


rcsponseTimeStamp 


Date 


time stamp when page was fabricated 



AU of the above mentioned attributes will have get and set methods. Following is the list of constructors for 
this object: 

1 . PageRequestBLock(String URI, int depth): assumes that this PRB is the first PRB 

2. PageRequestBlock(String URI, int depth, PageRequestBlock originator): assumes this PRB inherits 
userlD, appID and respID values from originator. 

3. PageRequestBlock(Strmg URI, int userlD, int appID, int respID, int depth, PageRequestBlock home) 

Who construct PRBs? 
I . startLoader constructs entry point PRBs (uses constructor 1) 

2. URLCollector constructs PRBs from a given PRB response stream (uses constructor 2) 

3. BenefitAnalyzer modifies PRBs to set the weight and requestTimeStamp attributes 

4. PageGenerator modifies PRBs to set the responseTimeStamp attributes 

3.1.2 Policy T^le ^^T) 

The Policy Table stores information to tune the prefabricator system, 

A(MhJstrafors will <*aSgure the policies using the Admin Console. The policies are striped by 
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application and persisted in the database When the nr*fck«o,*^ • ^ ^ , ' ~ 

The policies supported by the policy table are: 

• DsEth: defines how deep down from the home page is candidate for fabrication. 



CPU consumption limit- the maximum CPU 



power available for the prefebricator 



• Responsibilities : define for which responsibilities we should prefabricate 

• Refresh interval : defines how often a page should be re-fabricated 
The following table is an example of the policy table 



App ID 


Depth 


CPU consumption limit 


Responsibility 


Refresh interval (sec) 


690 


2 


60% 


Managers, 
Representatives 


3600 


670 


1 


60% 


Managers 


10800 



The PoUcylnfbrmation Class models each row of the policy table. This class will take care of oersi 
Ioadmg and saving to database. The following accessor methods win be used P 



istency, 



public int getDepthO 

public void setDepthfint depth) 

public int getCpuConsumptionLimitQ 

P^licvoidsetCpuConsumptionLimitfintcpuConsum 

public Vector getResponsibilitiesQ 

public boolean containsResponsibtlityflnteger resp) 

public void addResponsibilityffnteger resp) 

public void removeResponsibility(Integer resp) 

public void removeAllResponsibilityO 

public int getRefreshlntervalO 

public void setRefreshlntervalfint refreshlnterval) 

public void loadQ; 

public void saveQ; 



3.1.3 System Statistics (ST) 

tystemStattstics object contains run-time information about the system. 



ft is used to control the workload in the system for optimal throughput Data in mis obi*** enmni^ 
the ^formation in the PoHcylnfonnation object. Flowing infbSon ^^C^T 
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Attribute 


Data Type 


Description 


Depth 


int 


depth to which currently PRBs are processed 


FabricationRate 


int 


number of PRBs processed per minute 


CPUUtilizdtion 


double 


the current CPU utilization 


JservCount 


int 


total number of Jservs available for processing prefabricate requests 



r 



AU of the above attributes have get and set methods to access them. 

3.1.4 User Page Table (UPT) 

^ds* 6 ' PagB ^ ^ ofirformation about Prefabricated pages that the Benefit Analyze 
fnfnrmatinn <=tnr^ 

The User Page Table is a single column table with a list of Page Request Blocks. 



Page Request Block (PRB) 

The PRB contains information about a particular jsp page. It is populated by Start Loader, Benefit 
Analyzer and P«ge Generator. 



Mis, 
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atatimeorinbatches. Currently writes can be done 1 PRB 

APIs supported by the UserPageTaSr ' Aw * Wr SeCt,0a Followin S is * e «« of 

void add(PageRequestBlock) 
PageRequestBhck removePRB(String URI) 
void remove (PageRequestBhck) 

intsizef) r 
Vector getAll 0 

Vector find (int userlD, int appIB, int respID) ' * 

Vector find (String URISubString) 
PageRequestBhck find (String URI) 

Vector getPRBOrder By(DEPTH/WElGHT> int count, ASC/DESC) 
Who populates this table? 



Components that would write to the User Page Table are: 
Stan Loader 



During startup, the Start Loader generates all possible URL requests for the homepage These imr 
used to populate the User Page Table 4 nomepage, ineseURL 



are 



Page Generator 



URL Collector 



Given the URL of a prefabricated page from the Page Generator (assuming it is at level n), the URL 

i S: ™? 1 M ^ "P rc&bricati0 ^le« URL responses possible from flft prefabricated 
page. This list of URL are used to populate the User Page Table. 



Who reads this table? 



Benefit Analyzer 



Data Structure Requirements 

The data structure is still undecided But the requirements are as follows: 
Speed 



Version: 
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This table will be accessed very frequently. Given the huge size of the table (the number of D refehri^ 
pages), a very efficiently data structure to retrieve and store data is needed prefabricated 
Synchronization Needs 

Different threads may access the User Page Table at the same time and synchronization is needed tn 
Method of Traversal 

The Benefit Analyzer needs to access this table to obtain prefabrication information. Three methods of 
traversal are proposed for the time being. methods ot 

By Weight 

The Benefit Analyzer needs to access all pages with a specified weight. 
By User 

The Benefit Analyzer needs to access all pages of a particular user. 
By URL 

t?^^ ^f^' needs to «»» "J P a S« * particular url portion. One example is that it needs 
to access alljsp'softhe same name Otfasud.jsp). 




• Another method of traversal mat might be useful in the future would be to enable a user-defined 
key (e g- respID) to scan the table and retrieve pages. 

• Yet another possible method of traversal would be to scan the table by specifying the level the 
pages are at The usefulness of this feature is to be determined. 



3.2 Start Loader 



This component does the initial bootstrapping for the prefabricator system. Given the home page (entry 
point into anapplication), this component will generate all possible URL requests for the home page. The 
generated PRBs is populated in the user page table so that the benefit analyzer can use it. 

Requirements 

Given an application's home page (a jsp file name), generate valid URLs for all users who can access the 
homepage. 

Given any application page (a jsp file name), provide mechanism for the application developer to generate 
yaud URL requests for mis application page [Future] 

Implementation Details 

In order to provide a generic URL evaluation mechanism, a PRBEvaluatelnterfaa* is defined A defeult 
^M^?? 0 ^ mterfece is provided to handle the "home page- URL generation. Application 
developers can provide their own implementation of the interface to support other application page URL 
generation. Following is the PRBEvaluatelnterfece specification: 



Version; 
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getPRBsO: constructs a Vector of valid PRB objects 

getParameterNamesO: returns a String ar^y of URL parameter names that the page expects 

The default implementer of the PRBEvaluatelnterfece class does the following- 

given apphcatoon and a set of valid responsibility keys. P ' combmatlons for a 

construct a PRB object for each valid {userlD, appID, respID} combination 



3.3 Benefit Analyzer 



P ?u t Cf tba r ™ A State 0f * e P refebr icator system, Benefit Analyzer determines the next set 

222° p * receives PRBs t0 * processed from *• y^^SSS^St 



12 



Selection Algorithm 

As stated earlier the primary goal of the algorithm is to determine the next set of PRBs to be fabricated at 
any given state of the system. The algorithm needs to meet the following requirement- 
At system start-up time, determine initial workload set 

Filter (or select) PRBs to be processed based on the current fabrication rate of the system 

fte^erto^ 6 V™ < Specified m *» ^ * bIe . *»*d definitely process all 

me user home pages (ui other words, highest ranked PRBs) process an 

the algorithm should result in user home pages being always ranked the highest 
The algorithm uses the following information that is available to it at all times: 
all prefabricated pages (PRBs) 
policy information from the policy table 

staleness of home pages - indicated by the timestamp of the home page PRBs in the user page table 
current prefabricate rate - implicitly determined by the staleness of home pages (or highest ranked 

The algorithm works as follows; 

Ahj^ d m is added to the user page table; it calculates a weight for the PRB using the following 
weight = (I/depth) + k 

Oracle Confidential — — 
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where* ' ~ 

deptb = depth of the PRB in the tree, 

k = some constant to indicate the relevance of the URL to the responsibilities in the policy table 
Theabove formula will ensure that home pages will always have me highest WeightSSwed t the nevt 
depth pages and so on. Furthermore, home pages belonging to users of It rJZSmlu^^T 
k ' Pohcytablewillhavehigherweightthanthosethatarenot responsibility specified in the 

l^fXiT? I mi0Ute f ° r iMtanCe) me ana, y zer examjn « *e user page table to issue the 

At system start-up time, when current fabrication rate is not available, the benefit analyzer issues PRR, ,« 
• be processed m batches of a fixed size - 1 000 (for example). Also, it considers al.7e m in Se u2r 
page table Over tune, the PRBs considered will determine both on die weight and on of fte 

highest ranked frome page) PRBs. If home page PRBs are stale beyond an acceptable tim TSlSat 
the current fabrication rate is pretty slow. Therefore, the analyzer will focus only on the home pZs anf 
makes sure all the home pages get generated at regular intervals. «ie nome pages and 

Implementation Details 

The benefit analyzer provides the following services to be used by different components within the 

systems ■ 

Adding PRBs to be prefabricated into the user page table: 
addPRB(pageRequestBlock, timeStamp) 
addPRB(pageRequestBlock) 

addPRB(Vector pageRequestBIocks, Vector timeStamps) 

addPRB(Vector pageRequestBIocks) 

PRBFiiter: 

getPRBsO: returns a Vector of PRBs to be processed in a queue. This implements the selection algorithm 

g etNextPRBs(currentIndex, batehSize): returns a Vector of next set of PRBs to be processed (works like a 
cursor access) 

isPI^InterestingCPRB): returns a boolean to indicate if PRB should be considered for further processing 

The benefit analyzer executes as a thread that periodically wakes up, selects PRBs to be processed and 
issues these to the "Request Feeder". 

Future & Open Issues 

the selection algorithm can be more fine-tuned. One option is to factor in the fcnout associated with URLs 
at Afferent depths. If from a page one can navigate to n pages, then each of those n pages have a 
Probability of lut of 1/n (-p). Use this in the weight formula: w =p*(l/depth) + k. Another option is to 
factor in user hit counts in the weight formula. 

finalize the APIs associated with this component 

3.4 Request Feeder 

Request Feeder performs the page generation from the Page Request Blocks. 



Version: 
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Algorithm: — 
Tile Benefit analyzer puts PRB's in the incoming queue for page generation. 

The Request Feeder update the generated time in the PRB. 

The Request Feeder updates the current page generation rate for the PRB in the SystemStats object 
The generated PRB is put in the outgoing queue. The URL collector picks up the PRB. 

Open; 

Whether or not the PRF saves the HTML response as a fHe on the file system or the interceptor does it. 

Data Structure; 

queue J i^^^ ** *»» " « a ^ ™* type of the 



API's: 

QueneManager: 

public inter/ace QueueMartager 
{ 

public static final int LOW « 0; 
public static final int MEDIUM = 1; 
public static final int HIGH « 2; 



* returns the next QueueElement. The next QueueElement is chosen from 

* amongst the three Queues. The weight of each element is a function of 

* the time spent in the queue and the priority of the queue it is in. The 

* element returned is removed from the corresponding queue. 

* ©return the next QueueElement 

* ©exception oracleappsJtfMse.resources.Framewo^ if, 



an error occurs 



public QueueElement getNextElementQ 

thrttysFrameworkException; 
/*♦ 

* returns the next QueueElement. The next QueueElement is chosen from 
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* amongst the three Queues. The weight of each element is a Junction of 

* the time spent in the queue and the priority of the queue it is in The 

* element returned is NOT removed from the corresponding queue 

* @return the next QueueElement 

* ©exception oracleM P psMbase.r^ources.FrameworkException if an error occurs 
V 

public QueueElement peekNextElementO 

throws FrameworkException; 
/** . 

* returns the next QueueElement from the specified queue. The 

* element returned is NOT removed from the corresponding queue. 

* @param priority the priority of the queue. 

* @return the next QueueElement 

* ©exception oracle.appsjtfibase.reso if an error occurs 
V 

public QueueElement peekNextElementfint priority) 

throws FrameworkException; 
/** 

* adds a QueueElement to the specified queue. 

* ©param elem the QueueElement to be added . 

* @param priority the priority of the queue. 

* @return the added element 

* ©exception oracle.apps.jtfbase.resources. FrameworkException ifan error occurs 
V 

public QueueElement adaToQueuefObject elem, int priority) 

throws FrameworkException; 
/** 

* removes a QueueElement from any queue in which it is found 

* ©param elem the QueueElement to be added 

* ©par am priority the priority of the queue. 

* ©return the removed QueueElement 

* ©exception oracleMppsjtf.base.resources.FrameworkException ifan error occurs 
V 

public QueueElement removeFromQueue(Object elem) 
throws FrameworkException; 

* removes a QueueElement from Specified queue 
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* @param elem the QueueElement to be added 
*%param priority the priority of the queue. 

* ©return the removed QueueElement 

* ©exception oracle.app sm ase.resources.Fr ameW orkException if an error occurs 
V 

public QueueElement removeFromQueue(Object elem, int priority) 

throws FrameworkException; 
/** 

* removes the top from specified queue 

* @param priority the.priority of the queue. 

* @return the removed QueueElement 

* ©exception oracleMppsm^resources.FrameworkException if an error occurs 

public QueueElement removeFromQueue(int priority) 

throws FrameworkException; 
/»* 

* tells whether or not all the queues are empty 

* return true if all the queues are empty, false otherwise 

* ©exception oracleMpps^base.resourc^FrameworhException if an error occurs 
*/ 

public boolean isEmptyQ 

throws FrameworkException; 
/** 

* tells whether or not the specified queue is empty 

* @param priority the queue priority 

* return true if the specified queue is empty, false otherwise 

* ©exception oracleappsJtf.base.resources.Fram^ if m error occurs 
V 

public boolean isEmptyfint priority) 

throws FrameworkException; 
/** 

* tells whether or not all the queues are full 

* return true if all the queues are full false otherwise 

* ©exception oracleappsMbase.resources.Fw ff an m occurs 
*/ 

public boolean isFuilQ. 
throws FrameworkException; 




/** 

* tells whether or not the specified queue is full 

* ©param priority the queue priority 

* return true if the specified queue is fall, false otherwise 

* ©exception oracle.appsjtf base, resources. FrameworkException if an error occurs 
V 

public boolean isFullfint priority) 

throws FrameworkException; 
/** t 

* returns the size of the specified queue 

* @param priority the queue priority 

* ©return the number of elements in the queue 

* ©exception oracle.appsjtfbase.resources.FrameworkException if an error occurs 
*/ 

public int getQueueSize(int priority) 

throws FrameworkException; 
/** 

* returns the total size of all the queue 

* ©return the number of elements in the queue 

* ©exception oracle.appsjtf.base.resources.Fram tf an error occurs 
V 

public int getQueueSizeO 

throws FrameworkException; 
/** 

* returns the maximum queue size allowed for a-queue 

* ©param priority the priority of the queue 

* ©return the maximum queue size allowed 

* ©exception oracle.appsjtf.base.resources.FrameworkException if an error occurs 
V 

public int getMaxQueueSize(int priority) 

throws FrameworkException; 
/** 

'returns the maximum queue size allowed for all the queues 

* ©return the maximum queue size allowed 

* ©exception orade.appsjtf.baje.resources.FroM if an error occurs 
*/ 

public int. getAfaxQueueSizeO 



throws FrameworkException; 
/** 

* set the maximum queue size of the given queue 

* @param priority the priority of the queue 

* ©exception oracleMppsjtfMase.resources.Frame^orkException ifan 
*/ 

public void sethfaxQueueSizepnt priority) 
throws FrameworkException; 



error occurs 



} 



QueueElement: 

public class QueueElement { 

private Object element _; 
private int priority 
private long timestampj 



public QueueElementfObject element, int priority); 

public Object getElementQ; 
public int calculateRankO; 

public int compare(QueueElement qe); 



PageRequestFeeder: 

public class PageRequestFeeder 

f 

public PRE getElementO 
throws FrameworkException; 
public boolean putElement(PRB pr) 
throws FrameworkException; 
public boolean generatePRB(PRB pr) 
throws FrameworkException; 
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public float getPRBRateO 
throws FrameworkException; 



3.5 URL Collector 



HTML Pages 



► 


Crawler 






► 




< 


' . 





Valid URIs 



Repository 



JZSSS? Possib^ity of duplicates/circular-references the URL Collector wiU generate and store a unique Hashld for 
each uw lt generates. Each time a URI is generated, it's Hashld will be compared to the existing list o !f , 
match is found the URI will be discarded with the reasonable assumption thaHt has ak^ry^ra^ener^e^Ihfm^^as^ 
The same unique Hashld will also be used by the Interceptor for looking up cached pre -6bricated pages. 

3.6 Page Generator 



3.7 Page Iavalidator 



Three types of invalidation schemes are supported: 
• interval-based invalidation: requests for re-generating a particular URL are issued at regular intervals. The 
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• SparatextfAT AppendixTitlcCT ChapterTitleJ 
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, following iofomuuon: ~ « °^'««»' «*•». «■ W l.cM.on fcvotoper would bave to re^Lrthe 
• ^" to «^|''»b«ali s tonsPpa g e S ,„ r | iaofpmeWraImf „ , . 




- more details on this issue are addressed in the following interceptor section 

- it Calypso is used, it would handle this 

baS ? ™ vali(lation ' 1116 interceptor has to communicate to the invalidate- 

- more details on this issue are addressed in the following interceptor -erinn 



3,8 User Session Management 

User session management has to be done at two levels: 
• ^P«***atariMra 
" w^ai^rt^itionstomar^fabricatedpa^^ 

This section describes how the above two cases are lifliirfi^ t„ + ^ 

Takes userlD, appID and respID as inputs 
Authenticates a special prefabUser 

Switches user session context to that specified by userlD - invokes setUser 

5. s ^^*^wiftoompteteUiafbrft e bo™^ 

^S^JT" "J?*!* "* ""Wr *» *= «os»tooID to be the am. ,, thMcnatedfb, 



1. 

2. 
3. 
4. 



3.9 Interceptor 

^isoomponent Intercepts the URL requests, determines if the request can be serviced from fte cache or 

15 ' 
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not The basic algorithm implemented by the interceptor is as follows: 

Check if request is from prefabricator or from user (by examining a parameter in the request object): 
If from user: 



If not present in cache, s 



srvice the page 



%2££2£Z^ mmk 311 pages 35 inva,icL Dependent p " ages « in * -* 

If from spider: 
Service the page 
Store response in the cache 
In either case, response should also be T-d to the URL Collector component of the prefabricator. 

Open Issues 

How efficiently can the response-T be implemented? 

When there are multiple apache hosts, how does synchronization of invalidation information get 
propagated? & 

- could range-partition requests by userlD across different apache hosts. This will maintain user-level strict 
consistency, but not strict consistency across multiple users. E.g. : sales representative updates a report 
manager would want to see it But how much strict consistency is actually needed? 

Within a single apache host, how does synchronization of invalidation information across multiple Jservs 
work? r 

- if implemented in C, can use shared-memory 

- plug-in our own "load-balancing" algorithm into apache, so that requests from a range of users is always 
sent to a specific Jserv. i.e., range-partition by userlD across Jservs 

Need clear design of ssoCookie update mechanism 

3.10 Cache 

The cache provider needs to support the following: 
store response in the cache based on a key 
get response from the cache based on a key 

by-pass the cache, and actually hit the server on-demand (specifically needed from Calypso which is a 
cache and reverse-proxy) 

modify response object with interceptor specified information (such as cookies) if the cache is handling 
the returning of the response (specifically needed from Calypso which is a cache and reverse-proxy) 

Open Issues: Calypso Requirements 

pass-through to service the request, rather than using the cache 

modifyRfisponseHeader(..) - ability to modify the response header before sending to client 
Vml0n: ~ " Oracle Confidential — ~2T 
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4 Internal APIs/Classes 



SeSSg ST C ° ,leCti0n *»*» * ey Sh ° Uld a » be "ere (reference the 

« the number of round trips f 

a description of what the function does 
a the input and output parameters and descriptions ' 

■ Pass by ref; value, pointers 

n null pointers expected to be initialized, or Ok to return empty 

o memory allocation/deallocation, e.g. if client allocates, they deallocate 

lfull d T 1 CIU kk S Cl T*\ lt Sh0Uld Similar informati ^ about the classes, how they relate to 

each other (preferably with a class hierarchy diagram), and all of the attributes and methods ofLh class. 

Similar information is to be provided for QCI, PRO, and Java interfaces. 
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B Glossa 



If your project uses a lot of terminology that may be new to your reviewers you should cn ™,w aa- 
glossary section. Otherwise, just describe it in the Concepts section ^ 8 



<term> 

<definition> 

Examples: 

Gizmo 

A peculiar construct. 



Widget 

A widget is an instance of a gizmo. 
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D Open Issues 



delude this section in all review copies of the specification. List all 
the design. 



open issues and identified risks with 
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Oracle CRM 11/ "Hornet" Release: 
JTF Page Prefabrication 



CRM Technology and Architecture 



CRM Technology & Architecture; Paga Prefabrication 



What is JTF Prefab Solving? 



* 20 Milli Sec Page Retrivals .vs. Few Sees 

* OSO Pages for Sales, Marketing personnel 

- Page Content Is Dynamic based on the user 
Caching will NOT Solve it 

- Prefabricate it (my.yahoo.com)! 



CRM Technology & Architecture: Pago Prefabrication 
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JTF Prefab 

Applications (OSO) Should Provide 

• List of JSP pages in application (70 pages) 

• List of read-only JSP pages (30 pages) 

• APP IP, RESP ID for the application 

• No Changes To Application Software & 
Database Schema ( non-intrusive ) 
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> CRM Technology & Architecture: Page Prefabricalion 



JTF Prefab 
OSO Prefabrication 

• Total JSP pages: 75 

- read-only pages: 30 

• For a sales force of 1 00: 

- 3000 pages to prefabricate 

- generate per min or 10 mins 

• MY.YAHOO.COM: 

- 6 million pages 

- every few minutes 

CRM Technology * Architecture: Pag« Prefabrication 
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JTF Prefab 

Dynamic -> Static Page 

Clients 
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IAS Web Cache 
Calypso Invalidation 




GET /x-oratilo-ca Che-invalidate HTTP/1.0 
X-oraelo-Cacne- Invalid* te-URL-Pxaf i * ; /<t a talog 
X-Orade-Cachp-rn vaiidato-L^veX ; 0 

Invalidate all URU starting with /cb tzloa (e.fr firtirc catalog 
with severity of 0 (i.e„ never sen? these pages stale) 
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JTF Prefab 
Working with Calypso 



Clients 
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JTF Prefab Service 
Application Components 




JTF Prefab Service 
Algorithm 

• For RESP ID, APP ID: 

- Get the list of FND USERS 

- Run the prefabricator at n min (10 min) intervals 

• Reduce # of pages to prefabricate using: 

- user access pattern 

- usage statistics 

- etc. 
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JTF Prefab 
Invalidation Policy 

• Timer based invalidation: 

- configure intervals for page regeneration 

• Login based invalidation. 

- when user logs in, re-generate user-specific 
pages 

• Event based invalidation: 

- transactional URLs invalidate set of dependent 
pages 
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Caching .vs. Prefabrication Solutions 



Caching 



Prefabrication 



Problem Repetitive fetching First time login of 
of same content user access patterns 
Solutions Reactive Pro-active 

Pros App. Neutral, App. Specific, 

Utilizes excess CPU 
& Disk on mid-tier 
boxes. 

Com Slow for first lime Too many pages 
user access. prefabricated 
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CRM JTF: 

Page Prefab rication Schedule 




CRM JTF : 

Page Prefabrication Schedule 



Phase Lute Functionality 



0 40KKk Session Mgmt, Intercept URl 

requests & serve Fab-Pages 

/ Refresh Sales & i STORE pages 

in 'm' minutes 
. // ^flBV Feedback of HOT users/ pages 

/// MBV Selectively Fabricate pages & 

_ "N n Mid-tiers support 
KV Set up and Admin Screens 

V ^KKKP Release 

Risk Selectivity Algorithms & Base 
of set up, 
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